1. Field of the Invention
The present invention generally relates to an improved method for starting application tasks in a multi-tasking operating system, and more particularly to an adaptive building method in which a task, once set-up and run, is saved in a set-up but idle state, forming a pool of available tasks.
2. Description of the Prior Art
As will be appreciated by those skilled in the art, in the OS/2 (a Trademark of IBM Corporation) multi-tasking operating system, application program requests are made to the operating system through an application program interface (API). A request starts a task; a task may be either a process, thread or session.
A thread identifies a dispatchable unit of work (a program runs within a thread). A process is a collection of one or more threads and associated system resources (such as memory, open files, and devices). A session is a collection of one or more processes associated with a virtual console (keyboard, video display, or mouse).
The basic unit of execution in OS/2 is the thread. Every process in the system has at least one thread. The thread provides program code with an execution environment that consists of the register values, stack, and the CPU mode as the thread's context. OS/2 automatically maintains the correct context for each thread. An application may employ one or more threads. For example, the application program reads from a diskette with one thread while it prints data with a second thread. Threads do not own system resources. Other than their own execution stacks, threads share the resources of the process. When all the threads of a process have ended, OS/2 terminates the process.
Program resources in OS/2 are grouped into logical units called processes. More precisely, a process is a collection of system resources allocated to a particular program. For example, the threads, memory, files, and devices created by a program all become part of the process.
Whenever OS/2 starts a program, it first creates a process to "own" the resources. OS/2 then loads the program and starts a thread to run the code. As the program allocates (or acquires) additional resources, they become part of the process. For example, memory segments, file, queues, semaphores, and threads are all resources a program may dynamically allocate.
Processes are created with the OS/2 DosExecPgm API. This API allows a caller to identify a program (EXE file) to be read in from disk and run as a process. If the program is already running, OS/2 creates a new process with a new execution instance of the code.
After a requested task has been set-up by the OS/2 API, control is passed to the application for execution. When control returns to the operating system, the task is terminated. FIG. 1 is a block diagram illustrating this prior art process.
The OS/2 operating system is described in detail in a publication entitled OS/2 Programmer's Guide, by Ed Iacobucci and published by Osborne McGraw-Hill, incorporated herein by reference.
While generally satisfactory, the OS/2 start-up process for a task is time consuming and can degrade overall system performance.